BMW Groupが超ハイレベルな新時代のグローバルデータ分析基盤を稼働させていた #ANT310 #reinvent

AWS re:Invent 2020

#レポート

#AWS Glue

#Amazon Athena

#Amazon SageMaker

#AWS

春田拓海 | Takumi

2020.12.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どうも！DA部の春田です。

本記事は、AWS re:Invent 2020のセッション動画、「ANT310: How BMW Group uses AWS serverless analytics for a data-driven ecosystem」のレポート記事です。

English version is here.

みなさんご存知、世界的な大企業BMW Groupですが、最近ローンチしたと言われる全社活用のグローバルデータ分析基盤、Cloud Data Hubの完成度が凄まじかった…。

AWSインフラの知識がないBMW社員でも、AWSサービス群を最大活用できるデータ分析プラットフォームを構築しながら、社員であれば誰でもPRが出せるOSSとして社内限定に公開し、改善・機能追加のスピードを上げているのが、素晴らしいと言いますか、よくこれをBMW Groupのような大規模の企業で実現できたなと。データ活用を考えている大手企業必見の事例セッションです。

概要

データはBMW Groupのデジタルトランスフォーメーションを活性化させる燃料です。BMWのパーソナライズされた顧客体験や、コネクテッド・モビリティ・ソリューション、分析インサイトを進める動力源となっています。このセッションでは、BMW GroupがCloud Data Hubを構築するまでの道のりをご紹介していきます。BMW Groupのテクニカル・リード、Simon Kernが、自社がいかにAWSのサーバレス基盤を活用して、モジュラー化された、アクセスのしやすい、再利用可能なビッグデータETL基盤を構築・運用しているのかを深堀りし、次のステップに繋がるインサイトを提供します。ここでご紹介するサービスは、AWS Glue、Amazon Athena、Amazon SageMakerなどを含みます。

スピーカー

Simon Kern
- Lead DevOps Engineer - BMW Group

How BMW Group uses AWS serverless analytics for a data-driven ecosystem - AWS re:Invent 2020

内容

BMW GroupのIT活用について
Cloud Data Hub： BMW Groupの基幹データレイク
データ・オーケストラレーション
データの抽出と加工
データ分析
今後の展望

BMW GroupのIT活用について

BMW Groupは、世界60国籍、29ヵ国に展開するグローバル・モビリティ・カンパニー。世界694カ所が社内のITネットワークで繋がり、230以上のソフトウェアプロダクトを提供しているため、ITカンパニーとも呼べる。その中で最も重要なサービスの一つ、BMW ConnectedDriveのバックエンドでは、1400万の自動車が接続され、1日あたり10億ものリクエストが処理されている。

→ BMW Groupは、そのバックエンドで大量のデータを捌いている
→ データレイクへデータを流し、管理と分析を行いたい
→ Cloud Data Hubが登場

Cloud Data Hub： BMW Groupの基幹データレイク

クラウドネイティブなデータレイクのメリット
- データ投入のしやすさ
- ストレージがスケーラブル
- データから価値を見出しやすくする
左図
- 500以上のソフトウェア・データ・エンジニアが利用
- データ投入とデータ変換処理を構築し、マーケットプレイスに蓄える
右図
- 5000以上のビジネス・アナリストとデータサイエンティストが使用
- ユースケースや機会学習モデルの構築
→ データの民主化が実現、誰でも全てのデータへアクセス可能に

全てはData Portalを通して、シームレスに使用できる。

アーキテクチャ内部は、Data Provider、Data Consumer、Data Portal & API、の3つの柱で構成されている。全てマルチアカウントで構築・運用している。

データ・オーケストラレーション

Data Providers（左側）
- グローバルIT部門が提供する共通のデータセット
- ローカルのIT部門固有のデータセット
Data Consumer（右側）
- 図中央の別レイヤーでデータのアクセス権を管理
- グローバル部門はグローバルのデータセットのみ、ローカル部門はグローバルとローカルの両方にアクセスするなど
Data Portal & API（中央）
- ユーザーができること
  - データの検索とクエリ
  - メタデータの管理
  - インフラのデプロイ
- 数種類のAPIをベースに構築されている
- セキュリティ、コンプライアンスにも対応
- シングルサインオン
- グレーの枠
  - マーケットとリーガルで分割し、それぞれのハブで固有のアカウントとプロセスを持っている
- 統合されたシームレスなフロントエンド

Dataset
- S3バケットとGlueデータベースの組み合わせ
- 必ずHubの内側に存在する
- 複数のDatasetをカテゴライズするために、Business objectなるものに紐付けられている
- 各データセットは、以下の3つのレイヤーのどれかに分けられる
  - Source: ソースシステムからのコピー、生データ
  - Prepared: 前処理図済みのデータ
  - Semantic: 分析に使われる集計データ

データの抽出と加工

データ抽出のキーコンセプト
- Ease of use（使いやすさ）
  - GUIのTypescriptベースのCDKから構築やデプロイが可能のため、AWSの知識は最小限でOK
  - Terraformモジュールで、インフラの詳細設定
- Flexibility（柔軟性）
  - 小さくモジュール化された機能を組み合わせてシステムを構築
  - モジュールの再利用
- Maintainability（メンテナンスのしやすさ）
  - 社内オープンソースとして公開、全社員がPRを出せるコミュニティへ
  - Forkして使用も可能

オンプレからCDH Coreへのデータ出力
- 全てTerraformで構築
- Glue ETL
  - プライベートVPCで稼働
  - オンプレからデータを引っ張ってくる
  - CDHのS3バケットへ保存
- Secrets Manager
  - クレデンシャルを保存するデータベース
- Cloud Watch
  - ログ管理、Glueジョブのトリガー
- Glue Data Catalog
  - LambdaでProviderとCDH CoreのData Catalogを同期
- セキュリティアカウントは独立
  - KMSキーはここで保管
- PII API
  - センシティブデータはこのAPIを通して暗号化

データ前処理
- 別のTerraformモジュールを使用してセットアップ
- CDHのS3バケットからデータを取得（source layer）
- Prepare layerのデータセットとして出力

データ抽出での課題
- マルチアカウントによるS3オブジェクトの所有権問題
  - この構成だと、オブジェクトの所有権がバケットの所有権と合わない
  - バケットポリシーが適応せず、IAM RoleはGlueジョブとの兼ね合いが難しい
  - 最近のS3のアップデートにより解決、自動で所有権をスイッチできるようになった
    - Amazon S3 Object Ownership が利用可能になり、バケットにアップロードされたオブジェクトの所有権をバケット所有者が自動的に引き受けることが可能に
- Glueジョブのサイズ調節
  - Glue ETLで使用するDPUの適切な数の選択に苦戦
  - 自動化は難しかったので、ベストプラクティスに沿って決定した
  - 軽めのETLAWS FargateでオーケストラレートしたSparkで実行
- 細分化されたファイルの扱い
  - ストリーミングでは、出力ファイルが細かくなりがち
  - GlueとAthenaを使用した、合体（Compaction）用のモジュールを実装した

データ抽出まとめ
- 共通のタスクで使いまわせるモジュール
- マルチアカウントの設定
  - インフラの分離
  - 組織全体へスケールアウトのしやすさ
  - 個々のチームへ権限付与
- 150以上のシステムがデータをCloud Data Hubへ出力
- 1PB以上のデータボリュームに
  - 100TBまでは、PySparkベースのETL処理
  - 他はストリームデータとしてETL処理

データ分析

アナリストが使うAWSサービス
- Amazon Athena
- Amazon SageMaker（Amazon EMRやAWS Glue ETLも時に使用される）
- Amazon QuickSight
課題：誰でも実験環境から本番環境へデプロイできるようにすること
- データ抽出や加工をCI/CDへ導入
- プロダクトの新しいバージョンを構築するための管理された環境

デモの様子はセッション動画をご覧ください

アーキテクチャ -Data PortalとBitbucketを起点に異なるパイプラインへ展開 - 実験（Exploration）：データを探索し、変換用のコードを実装 - 開発（Development）：変換コードAthenaで検証 - 本番（Production）：開発で問題なければ本番へデプロイされる